We start by presenting some basic concepts to facilitate the understanding of the mechanisms that are presented further on.
Packets, Frames, Segments, Headers and Payloads
A data sender usually splits data to be sent into small units known as packets. Each packet consists of a header and a payload carrying the data to be delivered. The header contains fields defined by the relevant communication protocol. Within the payload of a packet, there will often be a further header, itself encapsulating a further payload. For instance, the great majority of packets carried by commercial networks nowadays are so-called TCP/IP packets, where TCP is the Transmission Control Protocol and IP is the Internet Protocol. In these cases, the network layer IP header encapsulates a transport layer payload that starts with a TCP header which in turn encapsulates its payload.
Similarly, when a packet is transmitted over a communications link it will be encapsulated by a further header specific to the technology of the link in question. For instance, when a packet traverses an Ethernet link, an Ethernet header is added to encapsulate the IP packet, which becomes the payload.
The general term for these split-up units of data is a protocol data unit (PDU). PDUs at different layers of encapsulation are typically given different names. At the link, network and transport layers they are termed respectively frames, packets and segments (or datagrams).
As will later be understood, embodiments of the present invention could be applied at any of these levels (or possibly even at the application layer, although it may be easier to extend a protocol without relying on embodiments of the present invention at the application layer).
Protocol Evolution
From time to time, a new requirement has to be met, and can be achieved by updating part of a communications protocol, rather than completely replacing it. Most protocols are defined so that some values of various fields are not used, but are “reserved” for future use. The idea is that new features can be added by bringing values into use from these reserved ranges.
When reserved values are brought into use for a new variant of the protocol, things generally do not go as planned. Existing equipment built before the protocol was updated is usually meant to take some default action if it encounters a packet carrying one of the reserved values. When a reserved value starts to be used, however, it is generally discovered that some legacy equipment does not take the specified default action, possibly for one of the following three reasons:                Precautionary security: some sites reject new-look packets as a potential security threat        Bugs: the new packets trigger bugs in some equipment that was never tested for all possible future variants of the protocol        Optimisation for the status quo: the new packets cannot be handled by hardware that has been optimised for the pre-existing protocol. So new packets have to be handled by software, which leads to a very high fraction of the newer packets being discarded because they cannot be processed fast enough.        
Therefore, the first adopters of a new protocol typically discover that arbitrary equipment seems to crash inexplicably, or packets carrying new values never reach their destination because some item of equipment wrongly discards such packets (termed being black-holed).
The outcome is often that new features are not deployed, because no company wants to bear the cost of all the support calls that will result when their perfectly-implemented update is seen as the cause of numerous problems that it triggers—problems that are actually due to all the other incorrectly implemented equipment that has already been deployed.